Lecture 8 — how an application's architecture shapes the way a DevOps team builds, deploys, and recovers it, and why the cloud changes the resiliency conversation.
"The architecture of a system mirrors the communication structure of the organisation that builds it." — Conway's Law, still true in the cloud era
A team's culture and pipeline only go so far if the application itself is built as one giant, tightly coupled unit. Today we look at the two dominant shapes software takes — and how each one changes the DevOps story.
All modules — UI, business logic, data access — are built, tested, and deployed together as a single artifact.
Simple to start, and for small teams or early-stage products, often the right call.
Each service owns one business capability — its own code, data, and deployment pipeline — and talks to others over the network (APIs / events).
Teams can build, deploy, and scale each service on its own schedule.
| Dimension | Monolith | Microservices |
|---|---|---|
| Deployment | Single unit, all-or-nothing | Independent, per service |
| Scaling | Scale the whole app | Scale only what needs it |
| Team structure | One team, shared codebase | Small teams, one service each |
| Fault isolation | One failure can affect all | Failures can stay contained |
| Best fit | Small teams, early-stage products | Large, fast-growing, complex systems |
Architecture decides how DevOps gets practised day to day. The shape of the system sets the shape of the pipeline, the ownership model, and even the on-call rotation.
A monolith needs one CI/CD pipeline; microservices need one per service, often templated.
Microservices push full lifecycle ownership onto the small team that built the service.
Distributed systems need distributed tracing and centralised logging to stay debuggable.
Resiliency is a system's ability to keep serving users — or recover quickly — when something inevitably fails: a server, a network link, a dependency, even an entire data centre.
On-demand compute, managed load balancers, and multi-region infrastructure let teams design for failure cheaply — something far harder to afford on fixed, on-premise hardware.
Run multiple instances so one failure isn't a service failure.
Add or remove capacity automatically as demand changes.
Spread traffic so no single instance is overwhelmed.
Continuously probe instances; remove unhealthy ones from rotation.
Stop calling a failing dependency before it drags everything down.
Automatically switch to a standby region or instance on failure.
Retry transient failures intelligently, without overwhelming the system.
Keep core features working even when a non-critical part fails.
Typically resilient through redundant copies of the whole app behind a load balancer, plus a strong database backup & failover plan.
Each service needs its own health checks, retries, and circuit breakers — resiliency becomes a property of every connection, not just the perimeter.
A two-person startup building an MVP and a large enterprise running a national e-commerce platform face very different problems. Discuss: team size, expected scale, time-to-market pressure, and existing DevOps maturity — which factors would push you toward a monolith, and which toward microservices?
Resilience process: Detect, Alert, Respond, Refine.
Think of an app you use daily — would you guess it's built as a monolith or microservices, and why?